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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 

Copyright (C) The Internet Society (2002). All Rights Reserved. 
Abstract 

This document defines the transport of Simple Network Management 


Protocol (SNMP) messages over various protocols. This document 
obsoletes RFC 1906. 
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1. Introduction 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies a MIB 
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module that is compliant to the SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 
[RFC2580]. 


This document, Transport Mappings for the Simple Network Management 
Protocol, defines how the management protocol [RFC3416] may be 
carried over a variety of protocol suites. It is the purpose of this 
document to define how the SNMP maps onto an initial set of transport 
domains. At the time of this writing, work was in progress to define 
an IPv6 mapping, described in [RFC3419]. Other mappings may be 
defined in the future. 


Although several mappings are defined, the mapping onto UDP over IPv4 
is the preferred mapping for systems supporting IPv4. Systems 
implementing IPv4 MUST implement the mapping onto UDP over IPv4. To 
maximize interoperability, systems supporting other mappings SHOULD 
also provide for access via the UDP over IPv4 mapping. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


2. Definitions 
SNMPv2-TM DEFINITIONS ::= BEGIN 


IMPORTS 
MODULE-IDENTITY, OBJECT-IDENTITY, 
snmpModules, snmpDomains, snmpProxys 

FROM SNMPv2-SMI 
TEXTUAL-CONVENTION 
FROM SNMPv2-TC; 


snmpv2tm MODULE-IDENTITY 
LAST-UPDATED "2002101600002" 
ORGANIZATION "IETF SNMPv3 Working Group" 
CONTACT-INFO 


"WG-EMail: snmpv3@lists.tislabs.com 
Subscribe: snmpv3-request@lists.tislabs.com 
Co-Chair: Russ Mundy 

Network Associates Laboratories 
postal: 15204 Omega Drive, Suite 300 
Rockville, MD 20850-4601 
USA 

EMail: mundy@tislabs.com 

phone: +1 301 947-7107 
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Co-Chair: David Harrington 
Enterasys Networks 
postal: 35 Industrial Way 


P. O. Box 5005 
Rochester, NH 03866-5005 


USA 
EMail: dbh@enterasys.com 
phone: +1 603 337-2614 
Editor: Randy Presuhn 
BMC Software, Inc. 
postal: 2141 North First Street 
San Jose, CA 95131 
USA 
EMail: randy_presuhn@bmc.com 
phone: +1 408 546-1006" 


DESCRIPTION 
"The MIB module for SNMP transport mappings. 


Copyright (C) The Internet Society (2002). This 
version of this MIB module is part of RFC 3417; 
see the RFC itself for full legal notices. 
" 
REVISION "2002101600002" 
DESCRIPTION 
"Clarifications, published as RFC 3417." 
REVISION "1996010100002" 
DESCRIPTION 
"Clarifications, published as RFC 1906." 
REVISION "1993040100002" 
DESCRIPTION 
"The initial version, published as RFC 1449." 
::= { snmpModules 19 } 


-—- SNMP over UDP over IPv4 


snmpUDPDomain OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"The SNMP over UDP over IPv4 transport domain. 
The corresponding transport address is of type 
SnmpUDPAddress." 
::= { snmpDomains 1 } 
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SnmpUDPAddress ::= TEXTUAL-CONVENTION 
DISPLAY-HINT "1d.1d.1d.1d/2d" 
STATUS current 
DESCRIPTION 


"Represents a UDP over IPv4 address: 


octets contents encoding 
1-4 IP-address network-byte order 
5-6 UDP-port network-byte order 
" 
SYNTAX OCTET STRING (SIZE (6)) 


—- SNMP over OSI 


snmpCLNSDomain OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"The SNMP over CLNS transport domain. 
The corresponding transport address is of type 
SnmpOSIAddress." 
::= { snmpDomains 2 } 


snmpCONSDomain OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"The SNMP over CONS transport domain. 
The corresponding transport address is of type 
snmpOSlAddress." 
:= [ snmpDomains 3 } 


SnmpOSlIAddress ::= TEXTUAL-CONVENTION 
DISPLAY-HINT "*1x:/1x:" 
STATUS current 
DESCRIPTION 


"Represents an OSI transport-address: 


octets contents encoding 
1 length of NSAP 'n’ as an unsigned-integer 
(either 0 or from 3 to 20) 
2..(n+1) NSAP concrete binary representation 
(n+2)..m TSEL string of (up to 64) octets 
" 
SYNTAX OCTET STRING (SIZE (1 | 4..85)) 
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—- SNMP over DDP 


snmpDDPDomain OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"The SNMP over DDP transport domain. The corresponding 
transport address is of type SnmpNBPAddress." 
:= { snmpDomains 4 } 


SnmpNBPAddress ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 


"Represents an NBP name: 


octets contents encoding 
1 length of object 'n” as an unsigned integer 
2..(n+1) object string of (up to 32) octets 
n+2 length of type ‘pop’ as an unsigned integer 
(n+3).. (n+2+p) type string of (up to 32) octets 
n+3+p length of zone "q! as an unsigned integer 
(n+4+p) .. (n+3+p+g) zone string of (up to 32) octets 


For comparison purposes, strings are 
case-insensitive. All strings may contain any octet 
other than 255 (hex ff)." 

SYNTAX OCTET STRING (SIZE (3..99)) 


—- SNMP over IPX 


snmpIPXDomain OBJECT-IDENTITY 
STATUS current 
DESCRIPTION 
"The SNMP over IPX transport domain. The corresponding 
transport address is of type SnmpIPXAddress." 
::= { snmpDomains 5 ) 


SnmpIPXAddress ::= TEXTUAL-CONVENTION 
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 
STATUS current 
DESCRIPTION 


"Represents an IPX address: 


octets contents encoding 
1-4 network-number network-byte order 
5-10 physical-address network-byte order 
11-12 socket-number network-byte order 
" 
SYNTAX OCTET STRING (SIZE (12)) 
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-- for proxy to SNMPvl (RFC 1157) 


rfcl157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 


rfc1157Domain OBJECT-IDENTITY 
STATUS deprecated 
DESCRIPTION 
"The transport domain for SNMPvl over UDP over IPv4. 
The corresponding transport address is of type 
SnmpUDPAddress." 

{ rfcl157Proxy 1 } 


{ rfcl157Proxy 2 } this OID is obsolete 
END 

3. SNMP over UDP over IPv4 
This is the preferred transport mapping. 


3.1. Serialization 


Each instance of a message is serialized (i.e., encoded according to 
the convention of [BER]) onto a single UDP [RFC768] over IPv4 
[RFC791] datagram, using the algorithm specified in Section 8. 


3.2. Well-known Values 


It is suggested that administrators configure their SNMP entities 
supporting command responder applications to listen on UDP port 161. 
Further, it is suggested that SNMP entities supporting notification 
receiver applications be configured to listen on UDP port 162. 


When an SNMP entity uses this transport mapping, it must be capable 
of accepting messages up to and including 484 octets in size. It is 
recommended that implementations be capable of accepting messages of 
up to 1472 octets in size. Implementation of larger values is 
encouraged whenever possible. 

4. SNMP over OSI 
This is an optional transport mapping. 

4.1. Serialization 
Each instance of a message is serialized onto a single TSDU [158072] 


[IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 
using the algorithm specified in Section 8. 
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-2. Well-known Values 


It is suggested that administrators configure their SNMP entities 
supporting command responder applications to listen on transport 
selector "snmp-1" (which consists of six ASCII characters), when 
using a CL-mode network service to realize the CLTS. Further, it is 
suggested that SNMP entities supporting notification receiver 
applications be configured to listen on transport selector "snmpt-1" 
(which consists of seven ASCII characters, six letters and a hyphen) 
when using a CL-mode network service to realize the CLTS. Similarly, 
when using a CO-mode network service to realize the CLTS, the 
suggested transport selectors are "snmp-o" and "snmpt-o", for command 
responders and notification receivers, respectively. 


When an SNMP entity uses this transport mapping, it must be capable 

of accepting messages that are at least 484 octets in size. 
Implementation of larger values is encouraged whenever possible. 
SNMP over DDP 

This is an optional transport mapping. 


Ls Serialization 


Each instance of a message is serialized onto a single DDP datagram 
[APPLETALK], using the algorithm specified in Section 8. 


-2. Well-known Values 


SNMP messages are sent using DDP protocol type 8. SNMP entities 
supporting command responder applications listen on DDP socket number 
8, while SNMP entities supporting notification receiver applications 
listen on DDP socket number 9. 


Administrators must configure their SNMP entities supporting command 
responder applications to use NBP type "SNMP Agent" (which consists 
of ten ASCII characters) while those supporting notification receiver 
applications must be configured to use NBP type "SNMP Trap Handler" 
(which consists of seventeen ASCII characters). 


The NBP name for SNMP entities supporting command responders and 
notification receivers should be stable - NBP names should not change 
any more often than the IP address of a typical TCP/IP node. It is 
suggested that the NBP name be stored in some form of stable storage. 


When an SNMP entity uses this transport mapping, it must be capable 
of accepting messages that are at least 484 octets in size. 
Implementation of larger values is encouraged whenever possible. 
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5.3. Discussion of AppleTalk Addressing 


The AppleTalk protocol suite has certain features not manifest in the 
TCP/IP suite. AppleTalk’s naming strategy and the dynamic nature of 
address assignment can cause problems for SNMP entities that wish to 
manage AppleTalk networks. TCP/IP nodes have an associated IP 
address which distinguishes each from the other. In contrast, 
AppleTalk nodes generally have no such characteristic. The network- 
level address, while often relatively stable, can change at every 
reboot (or more frequently). 


Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 
rather than by an "address". Hence, all AppleTalk nodes that 
implement this mapping are required to respond to NBP lookups and 
confirms (e.g., implement the NBP protocol stub), which guarantees 
that a mapping from NBP name to DDP address will be possible. 


In determining the SNMP identity to register for an SNMP entity, it 
is suggested that the SNMP identity be a name which is associated 
with other network services offered by the machine. 


NBP lookups, which are used to map NBP names into DDP addresses, can 
cause large amounts of network traffic as well as consume CPU 
resources. It is also the case that the ability to perform an NBP 
lookup is sensitive to certain network disruptions (such as zone 
table inconsistencies) which would not prevent direct AppleTalk 
communications between two SNMP entities. 


Thus, it is recommended that NBP lookups be used infrequently, 
primarily to create a cache of name-to-address mappings. These 
cached mappings should then be used for any further SNMP traffic. It 
is recommended that SNMP entities supporting command generator 
applications should maintain this cache between reboots. This 
caching can help minimize network traffic, reduce CPU load on the 
network, and allow for (some amount of) network trouble shooting when 
the basic name-to-address translation mechanism is broken. 


5.3.1. How to Acquire NBP names 


An SNMP entity supporting command generator applications may have a 
pre-configured list of names of "known" SNMP entities supporting 
command responder applications. Similarly, an SNMP entity supporting 
command generator or notification receiver applications might 
interact with an operator. Finally, an SNMP entity supporting 
command generator or notification receiver applications might 
communicate with all SNMP entities supporting command responder or 
notification originator applications in a set of zones or networks. 
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5.3.2. When to Turn NBP names into DDP addresses 


When an SNMP entity uses a cache entry to address an SNMP packet, it 
should attempt to confirm the validity mapping, if the mapping hasn't 
been confirmed within the last Tl seconds. This cache entry 
lifetime, T1, has a minimum, default value of 60 seconds, and should 
be configurable. 


An SNMP entity supporting a command generator application may decide 
to prime its cache of names prior to actually communicating with 
another SNMP entity. In general, it is expected that such an entity 
may want to keep certain mappings "more current" than other mappings, 
e.g., those nodes which represent the network infrastructure (e.g., 
routers) may be deemed "more important". 


Note that an SNMP entity supporting command generator applications 


should not prime its entire cache upon initialization - rather, it 
should attempt resolutions over an extended period of time (perhaps 
in some pre-determined or configured priority order). Each of these 


resolutions might, in fact, be a wildcard lookup in a given zone. 


An SNMP entity supporting command responder applications must never 
prime its cache. When generating a response, such an entity does not 
need to confirm a cache entry. An SNMP entity supporting 
notification originator applications should do NBP lookups (or 
confirms) only when it needs to send an SNMP trap or inform. 


5.3.3. How to Turn NBP names into DDP addresses 


If the only piece of information available is the NBP name, then an 
NBP lookup should be performed to turn that name into a DDP address. 
However, if there is a piece of stale information, it can be used as 
a hint to perform an NBP confirm (which sends a unicast to the 
network address which is presumed to be the target of the name 
lookup) to see if the stale information is, in fact, still valid. 


An NBP name to DDP address mapping can also be confirmed implicitly 
using only SNMP transactions. For example, an SNMP entity supporting 
command generator applications issuing a retrieval operation could 
also retrieve the relevant objects from the NBP group [RFC1742] for 
the SNMP entity supporting the command responder application. This 
information can then be correlated with the source DDP address of the 
response. 


5.3.4. What if NBP is broken 


Under some circumstances, there may be connectivity between two SNMP 
entities, but the NBP mapping machinery may be broken, e.g., 
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6. 


6. 


6. 


o the NBP FwdReq (forward NBP lookup onto local attached network) 
mechanism might be broken at a router on the other entity’s 
network; or, 


o the NBP BrRq (NBP broadcast request) mechanism might be broken at 
a router on the entity’s own network; or, 


o NBP might be broken on the other entity’s node. 


An SNMP entity supporting command generator applications which is 
dedicated to AppleTalk management might choose to alleviate some of 
these failures by directly implementing the router portion of NBP. 
For example, such an entity might already know all the zones on the 
AppleTalk internet and the networks on which each zone appears. 
Given an NBP lookup which fails, the entity could send an NBP FwdReq 
to the network in which the SNMP entity supporting the command 
responder or notification originator application was last located. 
If that failed, the station could then send an NBP LkUp (NBP lookup 
packet) as a directed (DDP) multicast to each network number on that 
network. Of the above (single) failures, this combined approach will 
solve the case where either the local router's BrRq-to-FwdReq 
mechanism is broken or the remote router’s FwdReq-to-LkUp mechanism 
is broken. 


SNMP over IPX 
This is an optional transport mapping. 
1. Serialization 


Each instance of a message is serialized onto a single IPX datagram 
[NOVELL], using the algorithm specified in Section 8. 


2. Well-known Values 


SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 
Protocol). 


It is suggested that administrators configure their SNMP entities 
supporting command responder applications to listen on IPX socket 
36879 (900f hexadecimal). Further, it is suggested that those 
supporting notification receiver applications be configured to listen 
on IPX socket 36880 (9010 hexadecimal). 


When an SNMP entity uses this transport mapping, it must be capable 
of accepting messages that are at least 546 octets in size. 
Implementation of larger values is encouraged whenever possible. 
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7. Proxy to SNMPv1 


Historically, in order to support proxy to SNMPv1, as defined in 
[RFC2576], it was deemed useful to define a transport domain, 
rfcl1157Domain, which indicates the transport mapping for SNMP 
messages as defined in [RFC1157]. 


8. Serialization using the Basic Encoding Rules 


When the Basic Encoding Rules [BER] are used for serialization: 


(1) When encoding the length field, only the definite form is used; 
use of the indefinite form encoding is prohibited. Note that 
when using the definite-long form, it is permissible to use 
more than the minimum number of length octets necessary to 
encode the length field. 


(2) When encoding the value field, the primitive form shall be used 
for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 
IDENTIFIER (either IMPLICIT or explicit). The constructed form 
of encoding shall be used only for structured types, i.e., a 
SEQUENCE or an IMPLICIT SEQUENCE. 


(3) When encoding an object whose syntax is described using the 
BITS construct, the value is encoded as an OCTET STRING, in 
which all the named bits in (the definition of) the bitstring, 
commencing with the first bit and proceeding to the last bit, 
are placed in bits 8 (high order bit) to 1 (low order bit) of 
the first octet, followed by bits 8 to 1 of each subsequent 
octet in turn, followed by as many bits as are needed of the 
final subsequent octet, commencing with bit 8. Remaining bits, 
if any, of the final octet are set to zero on generation and 
ignored on receipt. 


These restrictions apply to all aspects of ASN.1 encoding, including 
the message wrappers, protocol data units, and the data objects they 
contain. 
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8.1. Usage Example 


As an example of applying the Basic Encoding Rules, suppose one 
wanted to encode an instance of the GetBulkRequest-PDU [RFC3416]: 


[5] IMPLICIT SEQUENCE { 
request-id 1414684022, 
non-repeaters 1, 
max-repetitions 2, 
variable-bindings { 
{ name sysUpTime, 
value { unSpecified NULL } }, 
{ name ipNetToMediaPhysAddress, 
value { unSpecified NULL } }, 
{ name ipNetToMediaType, 
value { unSpecified NULL } ) 


} 


Applying the BER, this may be encoded (in hexadecimal) as: 


[5] IMPLICIT SEQUENCE a5 82 00 39 
INTEGER 02 04 54 52 5d 76 
INTEGER 02 01 O1 
INTEGER 02 01 02 
SEQUENCE (OF) 30 2b 
SEQUENCE 30 Ob 
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 
NULL 05 00 
SEQUENCE 30 0d 
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 
NULL 05 00 
SEQUENCE 30 0d 
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 
NULL 05 00 


Note that the initial SEQUENCE in this example was not encoded using 
the minimum number of length octets. (The first octet of the length, 
82, indicates that the length of the content is encoded in the next 
two octets.) 
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dis 


10. 


Notice on Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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11. IANA Considerations 


The SNMPv2-TM MIB module requires the allocation of a single object 
identifier for its MODULE-IDENTITY. IANA has allocated this object 
identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB 
module. 
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13. 


Security Considerations 


SNMPv1 by itself is not a secure environment. Even if the network 
itself is secure (for example by using IPSec), even then, there is no 
control as to who on the secure network is allowed to access and 
GET/SET (read/change) the objects accessible through a command 
responder application. 


It is recommended that the implementors consider the security 
features as provided by the SNMPv3 framework. Specifically, the use 
of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the 
View-based Access Control Model STD 62, RFC 3415 [RFC3415] is 
recommended. 


It is then a customer/user responsibility to ensure that the SNMP 
entity giving access to a MIB is properly configured to give access 
to the objects only to those principals (users) that have legitimate 
rights to indeed GET or SET (change) them. 
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